持續流程對于DevOps 和敏捷開發至關重要。這些方法使團隊能夠以極快的速度和準確性發布功能、更新和修復。然而，由于某些相似性，不同連續過程之間的界限往往是模糊的。本文指出了持續集成（CI）、持續交付（CD）和持續部署（CD）之間的區別。繼續閱讀以了解有關這些做法的更多信息，看看哪一種最適合您的團隊。

持續交付與持續部署與持續集成：有什么區別

以下是這三種做法的簡要總結：

• 持續集成 (CI)：一旦開發人員簽入，CI 就會執行自動集成、構建和代碼測試。
• 持續交付 (CD)：使用 CD，在集成、構建和測試之后會發生自動發布過程。
• 持續部署 (CD)：通過生產管道的每個代碼更改都會啟動部署，無需人工干預。

持續集成、交付和部署以多種方式重疊。CI 是持續交付和持續部署的重要組成部分。持續部署涵蓋與持續交付相同的流程，只是發布是自動發生的。

下表比較了持續交付、持續部署和持續集成：

持續集成	持續交付	持續部署
具有快速反饋的全自動集成、構建和測試流程	CI + 帶有手動觸發的自動軟件發布流程	CI + CD + 全自動部署到生產
在開發人員簽入后立即發生	交付一直進行，直到團隊認為代碼已準備好交付	所有代碼自動直接進入生產階段
使用單元測試	使用單元和業務邏輯測試	可以使用任何測試策略
需要 CI 服務器來監控存儲庫	需要強大的 CI 基礎	需要強大的 CI 和良好的測試文化
團隊必須為每個新功能或錯誤修復編寫自動化測試	測試套件必須覆蓋足夠多的代碼庫	測試套件的質量決定了發布的質量
開發人員盡可能頻繁地合并他們的更改（至少每天一次）	團隊可以選擇使用功能標志	功能標志是該過程的重要組成部分

集成、交付和部署并不是相互排斥的。單個管道可以包含所有三種方法。許多CI/CD 工具可以幫助您設置和運行高效的管道。

持續集成 (CI)

持續集成涉及一系列自動步驟，這些步驟集成來自多個源的代碼、創建構建和測試軟件。

CI的主要目標是：

• 快速發布新更新
• 使獨立團隊能夠在同一個項目上進行協作
• 在潛在問題造成損害之前識別并修復它們

CI 還可能包括將新設計概念集成到DevOps 管道中。

CI 的工作原理

CI 需要使用持續集成服務器，例如Jenkins或 Bamboo。CI 服務器自動測試不同開發人員編寫的代碼。每當一組代碼或構建通過本地單元測試時，自動部署會將軟件帶到暫存環境。在那里，更新會經過進一步的測試，例如負載或手動探索性測試。然后代碼合并到主代碼庫中。

持續集成的好處

• 在幾分鐘內構建、集成和測試新的代碼段
• 開發人員在不影響代碼穩定性的情況下獨立開發功能
• 部署更快、更可預測
• 更少的生產錯誤
• 出現問題及時反饋
• 消除發布日的集成挑戰
• QA 團隊在后期手動測試上花費的時間更少
• 鼓勵代碼透明度和代碼協作
• 更少的上下文切換

持續集成要求

• 監控中央存儲庫的 CI 服務器（在本地或云端設置）
• 對每個新的改進、功能或錯誤修復進行自動化測試

持續集成最佳實踐

• 維護代碼存儲庫
• 始終自動化軟件構建
• 盡可能快地保持構建
• 進行自我測試構建（持續測試）
• 對基線的提交應該每天發生
• 在生產環境的克隆中運行測試
• 輕松獲取最新的可交付成果
• 使最新構建的結果透明

持續交付 (CD)

在 CI 之上，持續交付還在集成和構建階段之后提供了一個自動化的發布過程。手動觸發器控制部署到生產。

CD的主要目標是：

• 準備就緒時交付新功能
• 構建穩定、有彈性的系統
• 確保業務應用程序不間斷運行

持續交付依賴于人類來決定向用戶發布什么以及何時發布。部署速率取決于業務需求。

CD 的工作原理

開發人員通過 CI 流程添加改進、功能和錯誤修復。手動提交后，CD 工具通過自動部署管道獲取代碼。持續交付通常具有類似生產的暫存區域，但在最終版本中存在時間滯后。延遲允許在投入生產之前審查并手動接受代碼中的更改。

持續交付的好處

• 加速發布周期
• 更快的上市時間
• 準備和設置版本的時間更少
• 增加迭代次數可以減少風險、縮短恢復時間并讓客戶更滿意
• 在交付過程的早期發現錯誤
• 交付更高效、更安全
• 可預測的交付速度
• 更快的用戶反饋循環
• 開發人員做更少的手動工作

持續交付要求

• 強大的 CI 基礎
• 早期開發階段的優化
• 涵蓋足夠代碼庫的測試套件
• 功能標志，以防止不完整的功能影響生產中的用戶

持續交付最佳實踐

• 確保有一個強大的 CI 設置支持持續交付流程
• 調整您的軟件系統以適應 CD，而不是相反
• 自動化盡可能多的流程
• 使用短而寬的部署管道
• 在開發和生產之間至少有一站
• 以相同的方式部署到所有環境
• 從版本控制驅動更改
• 在管道中包含數據庫
• 監控和記錄交付管道

持續部署 (CD)

在持續部署中，每個代碼更改都經過一個自動化管道，應用程序的工作版本會自動發布到生產環境。與持續交付不同，持續部署沒有發布審批周期。由于沒有手動觸發器，此設置依賴于自動測試以防止錯誤到達最終用戶。持續部署的目標是實現幾乎不斷發布的更新。一旦開發人員編寫和測試代碼，用戶就會收到更新。

持續部署的工作原理

持續交付遵循按需模型，而持續部署則自動推動每個部署。在合并到主線分支之前，所有測試都在類生產環境中進行。持續部署不需要用于手動審查代碼更改的暫存區。自動化測試發生在開發過程的早期，并貫穿于整個發布階段。持續交付和部署之間的差異將繼續擴大，因為像Docker這樣的工具可以很容易地自動化應用程序部署。

持續部署的好處

• 無需人工干預的自動部署觸發器
• 將每個新的主線添加部署到最終用戶
• 團隊發展得更快（發布沒有暫停，手動重復性任務更少）
• 小批量代碼使發布的風險更低，更容易修復
• 統一的管道集成了團隊和流程

持續部署要求

• 一個優秀的測試套件
• 能夠跟上部署步伐的文檔流程
• 完善的功能標志系統，以支持重大更改的發布

持續部署最佳實踐

• 維護一個中央代碼存儲庫
• 盡可能多地自動化構建和部署過程
• 每天承諾基線
• 使用問題跟蹤器進行開發任務
• 使用包含問題編號和所有更改描述的版本控制分支

哪種持續練習適合您？

在您考慮哪種做法最適合您之前，請了解您的團隊必須擁有能夠處理 CI/CD 的 DevOps 文化。您還應該考慮潛在的限制，例如合規法律。法規可能會阻止組織使用持續部署。

如果您的團隊能夠支持持續流程，請問自己以下問題：

• 您的團隊是否需要在持續集成和交付之間手動觸發？
• 您是否能夠在未經利益相關者批準的情況下進行部署？
• 您可以讓您的用戶了解生產變更嗎？
• 您對生產錯誤的響應時間是否很快？
• 您的門控要求是否允許端到端自動化

如果您對上述問題的回答是肯定的，那么持續部署可能是一個值得的選擇。考慮自動化您的整個軟件交付，從代碼提交到生產。如果您對某些或所有問題的回答為“否”，那么您最好從持續集成和持續交付開始。考慮自動創建生產就緒代碼，但需要手動批準部署。隨著時間的推移，您的團隊可以繼續朝著軟件交付過程的持續部署和完全自動化發展。

做出明智的商業選擇

持續的流程有助于盡可能快地構建、測試和發布軟件，同時盡可能減少錯誤。然而，某些方法在某些情況下比在其他情況下效果更好。團隊必須了解持續集成、交付和部署之間的區別，才能充分利用這些實踐。現在您已了解每個流程提供的內容，請選擇符合您需求的選項，并輕松過渡到 DevOps。